home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part1 / 7652 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.pl1,comp.lang.c
  4. Subject: Re: PL/I and C
  5. Date: 27 Feb 1996 18:04:28 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4h066c$r0t@solutions.solon.com>
  8. References: <4gh5ru$eng@goanna.cs.rmit.EDU.AU> <4grhtv$s31@goanna.cs.rmit.EDU.AU> <4gt0tv$826@solutions.solon.com> <4gv8h0$3o2k@news-s01.ny.us.ibm.net>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <4gv8h0$3o2k@news-s01.ny.us.ibm.net>,
  12.  <Chris_harlow@artemis-intl.com> wrote:
  13. >In <4gt0tv$826@solutions.solon.com>, seebs@solutions.solon.com (Peter Seebach) writes:
  14. >>Yes, C's string handling is primitive.  It also has no hidden overhead.
  15.  
  16. >I'm sure you know C better than me but I know enough C to refute your
  17. >statement... for example:
  18.  
  19. >(1) The PL/1 equivalent of strlen() requires only a single load instruction.
  20. >      Wheres the 'hidden overhead'... you guessed it, its in the C library!
  21.  
  22. No, that's not hidden overhead.  That's *obvious* overhead.  Contrast PL/I's
  23.     string >= otherstring
  24. (not sure what the punctuation is).  Looks like a trivial operation, generates
  25. nontrival code.  (Sort of like the hidden overhead of structure assignment
  26. in C.)
  27.  
  28. >(2) My processor has a  move-n-bytes instruction.
  29. >     When I assign a string to a string in PL/1 the compiler knows in advance
  30. >    WITHOUT OVERHEAD how many bytes it is going to have to move and simply
  31. >    generates the required single instruction.  (even on cpus without move-n-bytes
  32. >    instructions, I have seen PL/1 generated code that performed 4-byte move
  33. >    instructions or load/stores until it was within 3 bytes of the end of the string..
  34. >    this is far more intelligent than having to check every byte for null..)
  35.  
  36. Yes, and is a fair trade-off if you want fixed-length strings.  C will let
  37. you produce objects which act sort of like strings but are fixed in length,
  38. and do the righ ops with them.  It generally isn't worth it.
  39.  
  40. Meanwhile, many modern C compilers have built-ins for all of the library
  41. functions, and do similar tricks for copying and moving strings.
  42.  
  43. >   Many have pointed out that C is rather lower level than PL/1 and I dont think
  44. >   anyone would disagree. My point is that the C language is sometimes at a 
  45. >   lower level than my processors machine code... this puts extra load in the 
  46. >   C string library... 
  47.  
  48. On the other hand, I've seen a *portable* C implementation of strfoo()
  49. outperform the single-instruction way to do it on the Pentium - because
  50. the C implementation was smarter than the P5.  You don't have to use
  51. a feature just because it's there.
  52.  
  53. > SO I think a better statement would have been:
  54. >   Yes, C's string handling is primitive AND it contains hidden overhead. 
  55.  
  56. No, just overhead.  None of it's hidden.
  57.  
  58. Are you telling me PL/I can't have a non-fixed length string, dynamically
  59. allocated?  If it can, the compare or copy functionality will do the same
  60. thing strcmp() and strcpy() do at some level.  If it can't, it sucks.  (Well,
  61. not really, but this is a language war, we have to say *something* rude.)
  62.  
  63. -s
  64. -- 
  65. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  66. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  67. FUCK the communications decency act.  Goddamned government.  [literally.]
  68. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  69.